Requirements engineering is the process by which an organization formally identifies a need and defines the goals of a product or system it proposes to develop in response to that need. The process takes many forms and is applied with varying degrees of formality in organizations ranging from small software development shops to Fortune 500 corporations, as well as civilian and military government agencies. It is applied in defining physical products, software systems, complex transnational industrial systems and an unlimited variety of other projects. Successful requirements engineering accurately identifies the goals the client organization hopes to meet via the proposed system, determines and documents the functions the system will have to implement to satisfy those goals, identifies the interfaces and inputs the proposed system will depend upon, the intermediate and final products or outputs the system will generate, the form these inputs and outputs will take, the criteria the inputs and outputs must meet, and a wide range of other considerations that can bear on the success of the project.
Throughout these phases of product development, communications in document form are employed to explain operational and functional requirements, implementation strategies, risks, operating instructions, adherence to regulatory and industrial standards, and other engineering parameters. One or more individuals create this documentation based upon their areas of expertise and their knowledge of and experience with the development project. The documentation is developed for different levels of understanding of the project and for different audiences to interpret and use the information to develop, manufacture or use the products created.
A review of requirements engineering documentation created at the various levels may reveal the use of language and terminology consistent with the parlance and vernacular of closed groups that internally use these terms to describe the technology. These terms, whose unique meanings are only understood by the closed group, may be misunderstood by external readers who mistakenly assume their knowledge of the term's potential usages is complete. Commonly, the meaning of these terms may be misinterpreted or an insufficient explanation is provided within the documentation, because the closed groups have sufficient knowledge to understand the meaning and therefore do not expand, define or reiterate the importance of certain aspects of the requirements, because their meaning is accepted as common knowledge within the closed group. The misinterpretation and misunderstanding of critical requirements may have disastrous results where a user of the technology makes an incorrect decision based on their misinterpretation of instructions or operational parameters of the technology. Users of the technology may further misunderstand the unclear terms where their use is inconsistent, and possibly ambiguous to those outside of the closed group.
An excellent example of the importance of providing clear and broadly detailed requirements engineering documentation may have been provided by the 2009 crash of Air France Flight 447 in route from Rio de Janeiro to Paris. The precipitating cause of the accident was the icing of external sensors that caused the flight control computer to get inconsistent airspeed indications. That system had been designed to automatically return control of the aircraft to the crew in such an event. However, no one in the cockpit had ever manually flown an Airbus 330 (or a 330 simulator) at cruising speed and altitude, while facing anything much like the array of erroneous or contradictory instrument readings, warnings and alarms they then confronted. In this example, the design of the aircraft created implicit expectations for crew performance that were not recognized or adequately addressed in requirements for design of the training program for flight crews.
This example may be dramatic and tragic, but it is not isolated. It has been estimated that failures traceable to the requirements engineering process (e.g., vague, imprecise, incomplete, inconsistent, inaccurate or unrealistic requirements specifications) cause 40% of the defects that arise in projects. Poorly constructed requirements specifications fail to communicate fully and accurately the client's expectations to the engineers who are charged with realizing the client organization's desires. This failure can not only lead to disaster on occasion, but also to billions of dollars wasted on mitigation work needed to correct errors and deficiencies.
The most basic and general tool in the requirements engineering process is a human natural language (e.g., English, Japanese, Swahili). There are various efforts to insert artificial languages or graphical/symbolic systems into the process, but the fundamental goal of a requirements engineering exercise is to capture the needs and expectations of a group of human users, who typically also bring to the problem a fund of relevant expertise that the requirements engineering process must capture. The natural language (or languages) the user community shares serve as the medium in which they discuss, analyze, and amend the devices, systems and practices that will be replaced by the proposed new system. Not surprisingly then, the majority of requirements are stated in a natural language and they are formulated largely by way of extensive interactions in natural language between requirements engineers or business analysts and the user community. Sentences in a natural language then are both the raw material for the production of a requirements specification and the medium in which the requirements are stated.
Current commercially available requirements engineering tools are intended to help users develop higher quality requirements specifications, but they address this problem at the level of project management by:
A. helping engineers organize and review inputs to the requirements engineering process,
B. providing tools for collecting and evaluating drafts of individual requirements,
C. cataloging and tracking connections and interactions between different components,
D. tracking requirements that have and have not been addressed once implementation begins,
E. tracking the testing and evaluation of the implementation to ensure that the criteria associated with specific elements of the requirement are in fact met,
F. and once a new system is fully deployed assisting in managing revisions to the requirements and the process of implementing and assessing the revisions.
These tools of the prior art, however, fail to assist in determining whether the requirements statements themselves are employing language that is clear and unambiguous, whether connections between different requirements are clearly articulated, whether there is consistency in the use of critical terms, whether conflicts or contradictions have been addressed and resolved, or whether the requirements accurately reflect the users' intentions and their expertise about the system to be developed. Some of the existing tools provide routine grammar- and spell-checking functions, but no existing product does anything to assess the quality, clarity and correctness of the requirements specification as a whole, as a textual language-driven document. Nor do they base their work upon research using valid linguistic and computational linguistic methods that identifies instances of language with high probability of miscommunication.
What is needed is a methodology that reduces defects caused by imprecise, vague, ambiguous, or incoherent linguistic communication in requirements specifications and other documents and a manner of identifying and storing unclear language, terminology and syntax to be used to amend and improve future documentation. Additionally, a method is needed that provides extensive interaction with all stakeholders of the system to increase their knowledge of terms (singly and in combination) and their implications and possible variety of meanings across the range of the application's use.